Audio visual player apparatus and system and method of content distribution using the same

ABSTRACT

A system is presented providing content to a plurality of handheld devices (including musical selections). The devices can access a server over the Internet via a Wi-Fi or other similar wireless interconnection and can download songs requested by a user from the server or from other users using, e.g., a P2P protocol. All downloads may be governed by applicable DRM rules. Content and playlists may also be pushed by a server from other sources and means including, e.g., podcasting, based on predetermined rules, favorite preferences of users, and other criteria.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to provisional application Ser. No.60/807,840 filed Jul. 20, 2006, and 60/943,675 filed Jun. 13, 2007 andis a continuation-in-part application of application Ser. No. 10/953,746filed Sep. 29, 2004, all incorporated herein by reference.

BACKGROUND OF THE INVENTION

a. Field of Invention

The present invention relates to the field of digital audio and videoplayer devices that are preferably portable and receive content eitherfrom a secure subscription-based service, “a-la-carte” content deliveryservice, or from other participant devices, and more particularly to aportable player apparatus that is in wireless communications with anInternet-based file server and/or to a peer player apparatus, at leastperiodically. The present invention also relates to a system and methodfor delivery and management of such content to such devices, andimprovements thereto.

b. Description of the Prior Art

The development of compressed digital audio and video formats, such asthe Motion Picture Experts Group—Layer 3 (MP3) audio compressionstandard, Advanced Audio Coding (AAC), Adaptive Transform AcousticCoding (ATRAC), Windows Media Audio (WMA), Free Lossless Audio Codec(FLAC), Ogg-Vorbis and others enabled the growth in popularity ofrecording, storing, transferring, and playing back digital audio andvideo data on computers, including personal desktop and laptopcomputers. In particular, compressed digital audio and video formatsenabled more efficient storage and transmission of high-quality audioand video content by reducing the amount of digital data that needed tobe stored and transmitted, resulting in data files that could be smallerthan 1/10th of the original uncompressed digital file withoutunacceptably degrading the quality of the output. However, due tocomputational requirements, consumers were generally only able to accessand use compressed and uncompressed digital audio and video on theirpersonal laptop and desktop computers (except for conventionalcommercially-sold pre-recorded CDs and DVDs, which were playable onstandard players connected to home stereos and the like). This severelylimited portable use and access to such digital audio and video contentin that it required the user to be present at or near his or hercomputer to see and/or hear the playback, which typically could only bethrough speakers and/or a screen internal to or connected to thecomputer and not easily transported in digital format to more favorablelistening environments, such as the user's car.

More recently, relatively low-cost, lightweight, compact, portabledigital media players (DMPs) have been developed, e.g., Thomson/RCA'svarious Lyra-branded products, Apple's iPod products, and Creative Lab'sZen line of portable MP3 player products. These portable devices enableconsumers to transfer compressed digital audio and/or video files storedon their computers to the portable devices through the use of associatedcomputer-based software via an external connection, such as a USB or“FireWire” cable, and to play the corresponding media on-demand throughtheir DMPs while not in proximity to their computer. Users most commonlyaccessed the audio on the device by connecting headphones via a standardjack on the device, although it was also possible to connect a line-outcable to other audio output or recording devices, such as a microphoneor line-input of a standard home stereo system.

Such DMPs originally tended to rely on the use of flash memory, such ascompact flash or secure digital, for the storage of audio content, andwere capable of holding a maximum of approximately 0.5 to 1 gigabyte ofmemory (and more recently 2, 4, 6 and 8 GB or more). So-called “portablejukeboxes” have also been introduced that can hold an estimated 10,000songs or more of musical entertainment by including a miniature harddisk recorder in the housing of the device, which can have 40 gigabytesor more of capacity. Portable video players with even greater hard diskcapacity have also been developed.

In general, conventional DMPs are capable of allowing their users to (1)transfer compressed media files from a computer to the device throughthe use of associated transfer management software installed on thecomputer and a physical connection to the computer, such as a USB cable;(2) store such compressed media files in non-destructive memory; (3)decode for playback any of a variety of compression algorithms; (4)convert a compressed or uncompressed digital file to an analog format,potentially also processing the signal to enhance the resulting soundand images; (5) process and amplify the resulting analog signal; and (6)produce high-fidelity sound and video for the user, which may be played,paused, fast-forwarded, rewound, skipped or replayed instantly andon-demand. Also, typically in the case of audio DMPs (e.g., the iPod“Nano”), the devices feature a relatively small digital display windowthat provides information regarding the audio content stored on thedevice, such as the title and artist, and enables viewing (and in somecases modifying) the sequence of the audio tracks that are currentlystored on the device.

Disadvantageously, however, data transfer and advanced sorting andsequencing of selections are difficult or impossible for a user toaccomplish unless the DMP is connected to the computer, which does notallow the user to obtain new content or to make other desirablemodifications to the content stored on the DMP, such as easily modifyingthe sequence of the content selections stored on the device while theplayer device is not connected to the computer. Further, in the case ofaudio, these players typically do not enable a non-technical user tocreate and manage custom “playlists” (i.e., fixed song sequences), suchthat a user can easily develop and use a variety of personalizedplaylists for use at different times. Also disadvantageously, thedisplay and user interface on these audio devices is typically limitedin size, involves the use of multi-functional buttons which are complexfor many users and is not touch-sensitive, thereby preventing non-expertusers from easily viewing and modifying the listing and sequence ofaudio tracks stored on the DMP.

A further disadvantage of the prior art is that users are typicallyrequired to select content selections one-by-one and then to add them tothe device. This requirement creates an inconvenience for the user sincetypically the user may prefer variety in programming and in many casesmay not want to create a selection-by-selection sequence ofentertainment, especially in the case of music. Programmed entertainmentof this sort is currently available to consumers through traditionalbroadcast media and through other means that generally require the useof a device connected to a wired input, such as Internet-basedstreaming, accessible through laptop and desktop computers (and certainspecialized wired devices, such as the Streamium audio device made byRoyal Philips Electronics, or Sonos digital audio products), and digitalcable television and radio services, accessible through cable-connectedtelevision sets. More recently, subscription-based commercial satellitebroadcast services have been introduced, such as DirecTV for televisionand Sirius and XM for radio, which enable consumers to receive broadcastprogramming by selecting among available stations.

However, in all cases involving terrestrial and satellite broadcasts,the user does not have true on-demand access to a large library (e.g., 2or 3 million items) of content, along with full transport control overpausing, skipping, repeating, fast-forwarding, rewinding and deletingcontent. Also, neither terrestrial and satellite broadcasts, norInternet-based media services, allow the user to call up and accessspecific new selections on-demand on a portable device (which ispreferably pocket-sized) that does not have full PC functionality (e.g.,a laptop) and is not connected to an Internet connection. Accordingly,for the convenience of receiving programming with existing DMPs, theuser is required to cede control over delivered content for convenience,or will be required to choose to cede convenience for control. Further,in the case of radio-linked audio player devices, player devicereception is typically limited due to physical terrain and geographicfeatures, which can distort radio signals that in all cases need to becontinuously present and stable during the audio output to provide theuser with a satisfactory entertainment experience. Further, of the formsof media services (e.g., TV and radio) available, only Internet-basedstreaming and digital cable, each of which require the user to use astationary wired-device for access (e.g., television set and digitalcable decoding box), and satellite broadcasts, which do not permiton-demand access or control by the user, provide digital-quality output,which may be a benefit required by users. The foregoing is partiallymitigated by the development of consumer devices that permit digitalrecording of broadcast content by the end user. However, these devicesgenerally have certain limitations: (1) The devices can store thedigital content locally only when it is broadcast, requiring the user towait for the broadcast to occur, and offering no opportunity for theuser to access a missed broadcast. (2) In the case of music inparticular, copyright and related laws limit the ability of thesedevices that receive broadcasts to be legally manufactured and marketedto consumers without explicit content owner approval, if such devicesenable the user to exert a significant amount of control over thecontent playback and management, such as the ability to rewind or repeata recording of broadcast satellite radio, or enable users to predictwith certainty that particular copyrighted music will be broadcast at aparticular time to enable the user to capture a digital recording.

A further disadvantage of the prior art is that a security method is notprovided for content owners to enable distribution of content to users,management of the content and deletion/expiration of their content on asubscription basis using only a standalone DMP that is not reliant onthe use of associated desktop or laptop computer software, while stillmaintaining royalty records and rights, especially against secondaryparty transfers. Content owners and users would also benefit from a waycontent can be shared laterally across peer-to-peer device transfers toother users of both the personal playlists and the media data contentthat may be stored in the player device in a way that is secure and thatpermits only authorized sharing activities.

It can be appreciated by one having ordinary skill in the art that theterms “audio”, “video”, “media”, and words of similar import may be usedinterchangeably throughout this document to describe the relevantcontent, since methods of digital video content compression, storage,transfer, playback and control can be accomplished by using very similarmethods and technologies and are similarly well-known by those skilledin the art. Note that “content,” as used in this document, shallaccordingly mean any audio or video recording that a user may seek toaccess, and also shall include any other file type capable of beinginterpreted by a user, such as a written document stored in digital formor a digitally stored and compressed photograph, which may be similarlytransferred, shared and used.

An apparatus and system that solves many of the problems associated withthe prior art has been previously filed as application Ser. No.10/953,746 incorporated herein by reference. The present inventionaddresses additional issues and improvements to the previously describedsystem.

SUMMARY OF THE DEVICE DISCLOSED IN THE PARENT APPLICATION

A preferred embodiment of the device disclosed in the '746 applicationconsists of a portable wireless audio and/or video player apparatus(which is preferably pocket-sized) having one or more of the followingelements: a peer-to-peer audio and/or video data transfer module toallow communications with another wireless audio and/or video playerapparatus; a wireless communication link to an Internet-connected base,a communication software module for requesting one or more audio and/orvideo data files from an Internet-based database server via theInternet-connected base station; a first security means for enabling thedownloading and storage of the requested files; a second security meansfor the management and playing of the stored files; and one or moresoftware modules for interfacing with a user to effect the foregoingfeatures using an easy-to-understand interface. More specifically, theplayer apparatus is able to function as a standalone device to generate,search and obtain new audio and/or video digital data files (containingcontent and associated metadata (as defined below)) wirelessly over theInternet, without the need to use an intervening device, such as adesktop or laptop computer that temporarily stores the content datafiles to be transferred to the portable device, or software that runs ona laptop or desktop computer to manage the transfer and arrangement ofcontent on the portable device. This feature enables a non-technicaluser to access and use digital audio and/or video content without botheror knowledge of how to operate a traditional PC computer. Further, toovercome the limitations of the display interface of the prior art, theuser interface software according to embodiments of the presentinvention is designed to enable more complex user functions and dataorganization, and to display these simply and clearly. Such userinterface software permits the device to reasonably and comfortablyfunction for the user as a standalone device while permitting the userto search for new content, manage and modify large volumes of content,and share content across a large number of potential users who may belisted by user ID or name. Moreover, the device obtains files from aserver or laterally from another device without using a browser-typeapplication.

It is also a feature of the embodiments of the previous device toprovide the user with a flexible programming capability both as to timeand selection for the playing of the individual audio and/or video filesor groups of files. This includes allowing a user to select and playindividual content selections from a broad content library stored in anetwork on-demand, and alternatively to request that hours of continuousprogrammed content be playable on demand, which programming will beupdated on a periodic basis (e.g., daily), without limiting the user'sability to start, stop, rewind or fast-forward through the program. Theservice operator would be able to set, control and enforce theapplicable user access rules based upon desired legal and/or contractualconstraints and business objectives.

It is also a feature of the embodiments of the previous device toprovide a means for exporting the data content to one or more of aplurality of output devices, including headphones or a home or carstereo, or another storage and/or playback apparatus such as a desktopor laptop computer. Such export may be via either a wired or a wirelesscommunications link.

It is a feature of the embodiments of the previous device to provide aportable player apparatus that is not dependent on favorable physicalterrain and geographic features that are typically associated withwireless communications devices. This is mainly accomplished by thepre-storing of desired audio and/or video data and metadata contentwhile in the presence of a communications uplink for accessing/playingat a later time, at which time a continuous wireless connection is notrequired for navigating the metadata database or for a satisfactoryoutput of the stored audio and/or video content.

It is a feature of the embodiments of the previous device to provide asecure method for content owners to enable distribution of their audioand/or video content to mass-market consumers on a subscription basis.

In a preferred embodiment according to the previous device, a mediadistribution system preferably consists of a broadband network systemfor wirelessly distributing digital media files to multiple standaloneportable digital media player devices in which the devices are: (1)optimized for searching for, receiving and playing audio and/or videofiles, authorized obtainment from a network or peer device, managementand search of metadata and media content (even while no network orInternet connection is present), authorized playback and authorizedtransfer (such as to a peer device or digital computer) of digital audioand/or video files by a user; (2) capable of wirelessly transmitting andreceiving audio and/or video data files at “broadband” speeds viaconventional broadband protocols, such as that promulgated in the802.11x standards, both to and from a network which preferably includesInternet connectivity; and (3) able to communicate with an applicationservice in order to request and download encrypted audio and/or videocontent and associated metadata. Each portable player device preferablyincludes at least a first security means that disables playback andtransfer of media files, or that selectively enables such playback andtransfer when a subscription service is activated. The mediadistribution system preferably includes one or more Internet-baseddatabase servers wherein are stored digital audio and/or video datacontent in compressed or uncompressed form and associated metadata(i.e., descriptive or associative data concerning the content—in thecase of audio, this may include such items as length of track, name ofartist, name of song, name of album, encoding format and bit rate), anInternet application server interface that communicates individuallywith each portable device via a secure certification/authenticationlink, an upload manager that ensures the secure and efficient deliveryof data content files to each of the portable devices, and thecommunications network, thereby allowing the user to request, download,and store individual titles, groups of titles, and/or preprogrammedentertainment that fit particular criteria (such as genre or purpose(e.g., work-out, dancing)) on a periodic basis.

The audio and/or video content may be distributed to the portable playerdevices in encrypted form, capable of being played only when decryptedwith a particular private digital decryption key. The portable playerdevice (or apparatus) is preferably constructed with an internal clockthat is not settable or re-settable by the user (which is a necessarypart of preventing a user from avoiding the expiration and disablementof content for time-based subscriptions), but rather can only bedigitally set by establishing a secure and authenticated connection to asecure subscriber network that provides it with accurate time and dateinformation. The portable player device preferably also includes amonitoring module that records the time and date each time a contentselection is played or transferred by the device. The monitoring modulealso preferably includes a reporting module for transferring themonitoring results to the network (e.g., via the device's uploadmanager) when connection is made between the portable player device andthe network for any reason. The portable player device furtherpreferably contains software (supported by secure hardwareconfiguration) which enforces conditional access to the decryption keyby the playback mechanism, which conditions are preferably set by, andupdateable by, the server-side operator and might include ensuring auser is a current and valid subscriber to a content service, or a playcount limit has not been exceeded (other example conditions enforced bymechanisms on the player device, as opposed to the service, mightinclude detecting whether the DRM or security mechanisms have beentampered with).

In a second embodiment of the previous device, a portable peer-to-peerwireless communication player device for transferring audio and/or videoand related files to and from a second portable peer-to-peer wirelesscommunication player device, the portable peer-to-peer wirelesscommunication player device preferably comprises: a wireless transceiverunit for wirelessly communicating with external devices (such as peerdevices and digital computers); an audio output unit for playing audiofiles; a visual output unit for displaying video and/or displaying userinterface information (e.g., LCD screen or other existing or hereaftercreated output technology, which, in the case of user interfaceinformation, may also be replaced (as is familiar to those experiencedin the art) with a menu-driven audio output means); a controllingcomputing unit having a user input interface and a microprocessor; adigital storage means for storing digital data; and an included softwaremethod for operating the device, wherein the digital data preferablyincludes audio and/or video data content and playlists. Further, theaudio output unit preferably includes one or more from the groupconsisting of speakers and headphones, and the user input unit mayconsist of one or more from the group consisting of buttons, keys,joysticks, toggles, switches, keyboards, touch-pads and touch-sensitivescreen locations, which may include infrared, resistive, inductive andcapacitive sensing means. The software may include one or more of thefollowing modules: a communications module; a processing module; asecurity module; a user interface module; a resident database managementmodule; a storage and retrieval module; and a play module.

The user input interface of the second embodiment preferably includes aset of interactive screens displayed on the video output device, furtherincluding: the steps required for selection of one or more titles inresponse to screen display pages in order to generate a content requestlist for transmitting to the audio and/or video content distributioncenter upload manager and database. The security module preferablyincludes means for interaction with upstream base station to enable theoperation of the portable peer-to-peer wireless communication playerdevice; interaction with at least one second portable peer-to-peerwireless communication player device; and expiration of audio and videocontent files according to a set of subscription and usage rules thatmay be modified through programmed changes at the network/server level.Such rules may include, for example, prohibition on playing anysubscription-based content resident on the portable device unless thenetwork has authenticated and validated the subscription on the devicewithin the past 30 days.

In a third embodiment, a portable peer-to-peer wireless communicationplayer device for generating and wirelessly transmitting a playlist tolocal base station having an Internet connection to an Internet-baseddatabase server, and receiving an associated plurality of audio and/orvideo data content files, preferably comprises: a portable peer-to-peerwireless communication player device as in the second embodimentcommunicatively coupled to an Internet-based database server via a localwireless base station. In the third embodiment, the wirelesscommunications are preferably accomplished using a Wi-Fi protocol (orvariant, such as Wi-Max). The Internet-based database server:distributes stored audio and/or video content files in response toplaylist transmission request after first verifying that the requestingdevice has an authorized subscription; sends re-enabling messages to therequesting device to reset a local security module to generate a firstenabling action; sends disabling messages to the requesting device tocause the local security module to generate a disabling action if thedevice does not have an authorized subscription.

In a fourth embodiment, a secure subscription-protected communicationssystem for distributing audio and/or video data content to a portablepeer-to-peer wireless communication player device, preferablycomprises: 1) a portable peer-to-peer wireless communication playerdevice that generates a content request list via an interactive userinterface or by automatically determining a list of one or moreselections the user desires but which are not currently stored on thedevice (e.g., based on a preferred sequence of songs or videos the userhas compiled (a “playlist”), only some of which are currently stored onthe portable device); transmits the content request list to a local basestation; receives and stores associated audio and/or video filestransmitted from the local base station; transmits to and receives from,on-demand or in an automated fashion, content files from otherpeer-to-peer devices; displays a list of available content on the deviceto its user, as well as to other users who establish a wirelessconnection with the device; displays a list of possible content choices,even if not resident on the device, to the user; enables management of alarge quantity of digital content, including the development andmodification of custom playlists; plays audio and/or video files inresponse to user selection, if the subscription is valid; and disablescontent rendering if the subscription is invalid, such that the user isnot able to play the content on the device; 2) the local base stationreceiver that receives the content request from the peer-to-peerportable wireless communication player device; and transmits thereceived request to an Internet-based database server via the Internetcommunication link; 3) the Internet-based database server that: storesand manages a plurality of audio and/or video files that are accessibleby inputting associated titles or file IDs; tracks subscriptioninformation (e.g., such as access rights and expiration timing) for aplurality of portable peer-to-peer wireless communication playerdevices; tracks artist proprietary material and rights; tracks usage ofproprietary material on each one of the portable peer-to-peer wirelesscommunication devices; receives the content request list from the localbase station via an Internet communications connection; retrievesselected audio and/or video files indicated by the received playlist;transmits the selected audio and/or video files to the local basestation for re-transmission to the portable peer-to-peer wirelesscommunication player device; and 4) a local base station transmitterthat receives transmitted audio and/or video files from an upstreamdatabase server via the Internet communication link and re-transmits thereceived audio and video files to the requesting portable peer-to-peerwireless communication player device.

In a fifth embodiment, a secure subscription-protected mediadistribution system for distributing audio and/or video content files toa portable peer-to-peer wireless communication player device in responseto a received playlist, preferably comprises: 1) a peer-to-peer wirelesscommunication device that: generates a user content request list via aninteractive user interface (or in an automated fashion based on userpreferences that the user pre-selects, and/or a predetermined set ofrules or other criteria); transmits the generated request list to alocal base station; receives and stores associated audio and/or videofiles transmitted from the local base station; plays audio and/or videofiles in response to user selection, if subscription is valid; anddisables and/or expunges content if the subscription is invalid; 2) thelocal base station receiver that receives requests from the portablepeer-to-peer wireless communication player device and transmits thereceived requests to a database server via the Internet communicationlink; 3) the database server that: stores and manages a plurality ofaudio and/or video files that are accessible by inputting associatedtitles or file IDs; tracks subscription information for a plurality ofportable peer-to-peer wireless communication player devices; tracksartist proprietary material and rights; tracks usage of proprietarymaterial on each one of the plurality of portable peer-to-peer wirelesscommunication devices; receives the content request list from the localbase station via an Internet communications connection; retrievesselected audio and/or video files indicated by the received playlist;and transmits the selected audio and/or video files to the local basestation for re-transmission to the portable peer-to-peer wirelesscommunication player device; and 4) a local base station transmitterthat receives transmitted audio and video files from upstream databaseserver via the Internet communication link and re-transmits the receivedaudio and/or video files to the requesting portable peer-to-peerwireless communication player device.

In a sixth embodiment, a wireless communications system for selecting,downloading and playing audio and/or video data content using a wirelessprotocol which, in the present embodiment may be based upon the 802.1x(or similar) standards and related technologies (referred to herein,along with other wireless technologies now existing or hereafterdeveloped (such as Wi-MAX which may be substituted, as Wi-Fi),preferably comprises: a subscription-based database server furtherincluding: a first Internet connection; a plurality of audio and/orvideo data content files; and a translation and retrieval means fordefining and downloading a unique one of the audio and/or video datacontent files in response to an inputted title or file ID selectionrequest. The wireless communications system also preferably includes: alocal Wi-Fi base station, which has a second Internet connection incommunication with the first Internet connection; and a portablewireless communication subscription-capable player device, which furtherincludes: a selection means for generating at least one title or file IDselection request; and a Wi-Fi transmission means for transmitting thefirst title selection request to the local base station and thence tothe database server; a Wi-Fi receiving means for receiving the audioand/or video data content file downloaded in response to the transmittedtitle selection request; and a playing means for playing the downloadedaudio and/or video data content file.

The portable wireless communication subscription-capable player deviceof the sixth embodiment preferably further includes a security unit forcontrolling the operation of the unit in responsiveness to at least onesubscription status indicator. The selection means of the portablewireless communication subscriber player device may further include adisplay unit and a user input means, which may further include suchinput devices as a button, a touch-pad location on the display unit, ajoystick, a toggle, a key, a keyboard or a voice recognition inputmeans.

The portable wireless communication subscriber player device of thesixth embodiment preferably further includes a communication means forwirelessly connecting with a second portable wireless communicationsubscription-capable player device for the purpose of transferring databetween the two devices using the Wi-Fi protocol. The portablesubscriber wireless communication subscription-capable player devicepreferably includes means for selecting, downloading and playing audioand/or video data content (or, per the definition of “content” herein,any other data files) using a Wi-Fi protocol, comprising: a selectionmeans for selecting at least one from a displayed list of audio and/orvideo titles and generating at least a first title selection request;and a Wi-Fi transmission means for transmitting the first titleselection request to a local base station and thence to a databaseserver; a Wi-Fi receiving means for receiving the audio and/or videodata content file downloaded in response to the transmitted titleselection request; and a playing means for playing the downloaded audioand/or video data content file. The portable wireless communicationsubscription-capable player device of the sixth embodiment preferablyfurther includes a security unit for controlling the operation of theunit in response to at least one subscription status indicator.

DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a block diagram of a system with several devices owned byor accessible to one or more users, with each user being able to setcharacteristics and other data associated with the devices;

FIG. 1A shows examples of remote editing of a playlist;

FIG. 1B shows a block diagram of a system implementing some advancedpeer-to-peer features;

FIG. 1C shows a block diagram for the device 10 adapted to processcatalog lists;

FIG. 1D shows a flow chart illustrating DRM license prefetching process;

FIG. 1E shows a flow chart of users receiving recommended lists ofmusical selections;

FIG. 1F shows a combined flow chart and block diagram of an example of aP2P file sharing protocol across wireless portable devices;

FIG. 1G shows a flow chart of audio file transmissions between buddies;

FIG. 1H shows a scheme for adding a song to a playlist;

FIG. 1I shows a flow chart for adding a song to a playlist;

FIG. 1J shows a flow chart for downloading a song to a device through atelephone;

FIG. 1K shows a block diagram for accessing content through via anylandline or mobile phone;

FIG. 2 shows a flow chart for downloading content on a portable devicesequentially from several sources;

FIG. 3 illustrates a system in which new content listings are providedto an intermediary server system, compiled (and optionally compressed)into a format that is compatible with an end-user mobile device;

FIG. 3A shows a block diagram for accessing content through cellularphones;

FIG. 4 illustrates a system with security means employed between anend-user device and an intermediary server system in which theintermediary server system handles a request for content that involvesone or more security means (such as DRM) for the device, insulating thedevice from changes to the security protocol over time and otherproblems that may arise;

FIG. 5 illustrates a user sets preferences on a PC (or on a mobiledevice) and have the server generate playlists/content whichautomatically get sent to the end user device.

DETAILED DESCRIPTION OF THE INVENTION

Feature 1—Profile Selection Remote from the Portable Device

In the original system described in the parent application, the emphasiswas on the portable device. The portable device was set up to allow auser to make all the changes in the user profile itself. However, insome instances, a user may prefer to make changes in his profile from adesktop or laptop computer because these latter devices have biggerscreens and, generally, more full-functional interfaces or anotherdevice, merely because the user has convenient access to the device atthe time he/she wishes to make the changes. A system performing thisfunction is shown in FIG. 1.

In FIG. 1, a system 100 is shown in which a user owns, operates or hasaccess to several different devices, two such devices labeled 10 and 12being shown in the Figure. Each of the devices has access to a contentserver 14 over the Internet 16, using a wired or a wireless connection(e.g. WIFI) and with or without a browser. Through each device, the usercan access his account on the server 14, using a user name, password,etc. Once he gains access to his account, the user can then make variouschanges, such as his address, telephone number, preferred credit card,etc. Moreover, the user can also make changes to his profile, includingthe genre of music he likes to hear, or can modify his lists of songs.In addition, the user can also modify various settings for any of thedevices associated with his account.

For example, device 10 may be a desktop PC and device 12 may be aportable music player. The user can access the server from eitherdevice, as discussed, or change the personal information, profileinformation, etc. He can also check or change various settings on theportable music player from the desktop. For example, the player may havea privacy setting that stops other devices from accessing anddownloading selections from the player. This privacy setting can beenabled remotely from the PC.

All the changes made by the user are entered on the user's account bythe content server 14 and stored in an account memory or database 18.This process is preferably implemented using an Internet web-based thinclient. The next time the user accesses his account using the portableplayer 12, the player automatically downloads the new settings,including the privacy setting, as well as other information relevant toits operation.

Feature 2—Remote Editing of a Portable Device Options

Another feature of the present invention is that, using for example, thesystem 100 of FIG. 1, the user can use on a device, such as device 10 toedit information on device 12. For this purpose, various lists and otherdata, such as addresses, telephone numbers, lists of songs that the userhas downloaded and their arrangement, are all stored in the accountmemory or database. Other information and actual content is stored inthis manner as well, including musical selections, such as songs,multimedia content files, e-mails, pictures, and so on.

While device 10 may be in contact with the content server 14 at alltimes, device 12 need not be. Once the user gains access to the server10, he can make the changes to both the various lists as well as thefiles containing content as well. For, the user can change these lists,by arranging them, adding or deleting items from the lists, etc.Similarly, the user can rearrange the content in memory 18, or evendelete the same as desired.

Contact between each device, therefore, could be establishedcontinuously, sporadically, when Wi-Fi service is available, atregularly scheduled time, or when requested by the user. The next time,the user accesses the content server 14 with any of his devices, theinformation in the respective device is updated using a sync operationsimilar to the ones used in PDAs. This process can also occurautomatically or when requested by the user. If the updating or syncoccurs automatically, the user has the option of disabling it. Thisprocess can also allow users to send information (including text, audio,video, and other media) to other users. For example, one of user A'sdevices 10 can send information to user B's device 12 in a similarfashion, if desired. FIG. 1A shows an example flow chart forimplementing these features. In FIG. 1A, the user can log into hisaccount in step 502 and then modify his playlist in step 504, which isthen stored on the server in the database in step 506. In step 508, theuser's device later contacts the server. If any changes have been made(step 510), the updated playlist information is sent to the device instep 512. If not, the user can proceed with other device functions instep 514.

Features 3 and 4—Automatic Content Distribution and Podcasting

The present invention further provides a system for automaticallydistributing new content directly to end-user devices. Through the userinterface of a portable or other device, a user indicates preferencesfor particular “Gremlists™,” or “podcasts,” or otherwise indicatespreferences for other similar “push content” from the server via a userinterface (collectively referred to herein as “podcast”), which may bepresented to the user by content server 14 (as depicted in FIG. 1). Eachsuch podcast may include the latest edition of an audiovisual programand any previous editions that the publisher may desire to makeavailable (e.g., it may be a playlist of separate audiovisual programs).The user of a device of system 100 may sign up to one or more podcasts.The contents from the podcasts are then made available to devices 10 and12 from digitized media files stored on content server 14 or 20 (whichmay be internal or external to the service provider) whenever therespective device contacts the server for an update and/or when thecontent server 14 sends a message the devices that new content isavailable for downloading.

This may be implemented in multiple ways. First, the user can be givenaccess to a selection of podcasts either via the portable wirelessdevice 10 interface or via any other device 12, such as a PC with abrowser. The user can select a podcast for his/her account by entering(or browsing) a URL manually or by searching or browsing an aggregationof available podcasts stored on the server 14 (which may be updated bythe provider or by users from time to time)—this listing may be compiledby a server which aggregates available podcast content by periodicallypolling podcast URLs 20 and compiling and organizing the metadata. Thelisting of podcasts may be presented or made searchable/browseable bytraditional means on a browser-based device. However, preferably, thelist of available podcasts is also searchable and browseable (inaddition to online live searches against a server) via an asynchronouscatalog mechanism such as the one detailed in application '746. Thiswould allow a user to review metadata and select podcasts for his/heraccount with low latency, even if the device was not presently connectedto the Internet. Regardless, in all cases, for each podcast the user isgiven access to basic metadata fields, which at minimum include apodcast title and a listing of editions, but may also include short andlong descriptions, descriptive podcast edition titles, authorship, yearof publication, etc. The user can indicate a preference to subscribe orunsubscribe (or download any individual edition or group of editions)from any available interface.

In any event, through any of these available means the user indicates apreference for one or more such podcasts. The device itself then mayremember these settings, such that it may directly download, forexample, podcast content over Wi-Fi using a standard podcast protocolsuch as RSS XML or RDF XML and compatible software running on thedevice. (Preferably the system is designed so that the relatively largemedia files are always downloaded by user device 10 directly from theoriginating content server 20, and not proxied via an aggregator'sserver 14, which would cause inefficient bandwidth consumption.)Alternatively, a proprietary or modified protocol could be used.Regardless, though, preferably the server 14 would record the podcaststo which a user is subscribed in its account memory 18, such that a userwho lost a device could have these settings restored to a new deviceeasily. Other benefits are also made available—in particular, the usercould make changes to his/her listing of desired podcasts and podcastseditions via any available access to the server 14 (e.g., a PC device 12with a browser)—for example, subscribe to three new podcasts—and thosechanges would then be automatically reflected and sync'd to the user'smain portable wireless device 10. Ultimately, in all cases, this affordsthe user of the portable wireless device to gain access to the latestpublished podcasts, which are conveniently and asynchronously downloadedover a wireless link to the user's device with minimal user actionrequired, and the settings for which may be controlled from anyavailable device with eventual access to the server 14.

The new content can but need not be DRM-protected. (If content isDRM-protected, the device would need compatible DRM decrypting softwareand would need a means to provide an appropriate challenge to the DRMserver, including any necessary account or user authenticationinformation.) A device (such as 10) can then be set to periodicallyconnect to the server 14 during the times a network is available, and toautomatically download new content from the subscribed podcasts, so theyare available to the user without further user interaction. The newcontent can either overwrite the existing one or can be added to theearlier content and accumulated/appended, if desired. The user can begiven the option to save any edition to a permanent collection(potentially for a fee, enforced by secure device software and/or theDRM usage rights associated with encrypted content), or preferably tohave automated memory-management software delete old content as newcontent is downloaded and more space is required.

Advantageously, this feature is performed on a portable player andtherefore the content can be obtained without a browser, and in anasynchronous manner not requiring an always-on connection (e.g., for aWi-Fi or Wi-MAX device with on-the-go users). In particular, if RSS XMLsoftware is not available, a proprietary protocol, such as that used for“Gremlists™” push content downloading in the '746 application, could beused. Such a protocol would also have the benefit of insulating thedevice from changes to the RSS/RDF protocol over time used by thevarious providers, and to providing more security and control from aservice aggregator's point of view. It also offers a more efficienttransaction over the wireless link since a server can perform tasks inadvance of a connection, such as aggregating a list of updates if theuser is tracking many podcasts from multiple sources. Additionally, thedesign of this system is greatly beneficial where the service providerand operator of the aggregating server 14 desire greater control andseek to provide a more managed and fault-free experience for theirsupported mobile users, which may be driven by business and/or userexperience objectives.

Feature 5 Advanced Peer-to-Peer Functions

As mentioned above, an advantage of the present system is that it hasthe ability to perform various peer-to-peer functionality on a Wi-Fidevice/mobile phone/etc., e.g., hotlisting. Hotlisting may include auser creating a wish list of songs (or citeria for desired songs). Theserver monitors the hotlist of each its users, and when one of the songsis published or becomes available from a source (e.g., potentiallyanother user in the same community), the server 14 obtains the songthrough normal channels and makes available to the respective device ordevices, thereby fulfilling the wish list automatically.

Another aspect of the invention pertains to two devices provided withsuitable means, such as wireless or other networks, connections, usingadvanced peer-to-peer protocols and functions. When the devices detecteach other, they can exchange and share various data and contentincluding buddy lists, hotlists, playlists, etc. The devices can beportable wireless devices, PCs, etc. If one of the devices is a portabledevice with a Wi-Fi chip, it can connect wirelessly to a network(“infrastructure mode”)—for example, connecting to the Internet from aT-Mobile® hot spot. It also can connect to other (i.e., one or more)devices directly using Wi-Fi (“ad hoc mode”).

For these purposes, software on the wireless device uses an algorithmfor scanning available connections, preferring one connection above theothers (using predetermined criteria). For example, the device can firstseek to connect to the Internet through a Wi-Fi access point with thestrongest signal strength (in infrastructure mode), and if one isunavailable to automatically connect to other devices directly,wirelessly point-to-point (ad hoc mode). Other criteria may be used forselecting one device over others as well.

When connected to the Internet, the device (e.g., device 12) can show alist of other connected devices, either through a central server orthrough any of a variety of Internet peer-to-peer architectures. Ineither case, when the device connects to another device, the softwarecan enable a number of automated features for the convenience of theuser. For example, if the user is looking for a particular contentfile—such as a digital song or movie—the device automatically scans allavailable connections and, if the particular content file is found onanother device (either through the Internet or point-to-point), thedesired content is obtained from the other device. Software on thetarget devices provides a list of available content on that deviceautomatically when another device contacts it.

The device can also show additional information. It can also showinformation about the other users' status, such as, for example, showingon a wireless portable digital music player the current playing song onthat player (which may optionally be developed so as to update in realtime). The software also enables devices to beam or otherwise exchangecontent and other information, including songs, photos, videos,preferences, lists, text, etc., through the wireless connections(provided of course that these are allowed by the DRM rules of therespective content). Typically this feature is accomplished by sending amessage to a target device and giving the target device the option todownload content from the sender (or, alternatively, from a centralsource of the content, such as a commercial digital content distributionservice on the Internet). In an alternate embodiment, once a deviceknows what is on the other, the data can be exchanged either directly(if both devices are online simultaneously), or if the recipient is off,the sender can transmit the data to the content server 14. The server 14then stores this information in a database until it can be transmittedto the recipient when the recipient comes online. (Note: “transmitting”can occur in all cases via the recipient device “asking for” and“pulling” the desired content, in a client-server like fashion.) FIG. 1Bshows a block diagram of a system for implementing these features. Forthis purpose, the user device 10 includes a connection logic softwaremodule 606, a list of available content module 608 and wish list or hotlist module 610. The server 14 is associated with a of the various userwish lists, hot lists, etc. (602) and a database of available content604 for performing the processes described above.

Feature 6—Organization of Available Content in a Catalog

As mentioned above, one of the features of the present inventionpertains to the manipulation of various lists on the devices. One aspectof this feature is the organization of large lists (e.g., >50,000 items,or millions). Each list is arranged into multiple layers and sub layers.For music, each layer identifies a group of songs, for example by thefirst word of the title. The successive sublayers then include all thesongs containing or starting off with said first word. If variouseditions of the same song are listed, then various types of metadata(using, e.g., the artist, the length of the song, the date on which itwas released, etc.) are then used to differentiate the songs with thesame title. This feature is advantageous because it renders the listarranged in this manner to be easily searchable, even on the smallscreen of a portable player. In particular, users can easily andmeaningfully distinguish versions of the same song from one another on asmall display (e.g., when the identical song having the same title isreleased by the same artist on two different albums).

One new feature of the invention is the manner in which songs from alist are loaded. Initially, a list is created of the songs that are tobe downloaded into the portable player. This list may consist ofindividual entries from the user or a completed list entered as a fileby the user. The list can also be generated automatically based on thepreferences of the user, or downloaded automatically from the server orother users.

Once a new list is downloaded into a player, or an existing list isupdated, then the corresponding songs identified by the list aredownloaded into the player. A flow chart implementing this concept isshown in FIG. 2. In step 100, a player acquires a channel to a server(or other devices) through a Wi-Fi connection. In step 102 the playerdetermines if it has a new or incomplete list of songs that have notbeen loaded into the player yet. If it does not, then the playercontinues with other functions in step 104, including any of thefunctions described above. If there are songs to be downloaded, then instep 106 the first song to be downloaded is selected. In step 108 the IDof the song is transmitted to the server. (Alternatively, the system canbe constructed such that the server dictates the ID of the song(s) to bedownloaded.) In step 109 the server validates the request and determinesone or more available locations (such as a URL on an external contentserver 302) from which the request can be fulfilled, and makes thisinformation available to the device 12.

In step 110 the process of downloading the selected song is started.During the downloading process the channel to the server is monitored.If the channel is still opened, the process continues. If the channel isinterrupted then in step 112 the download process is halted and a markeris used to indicate what portion, or how much of the song has beensuccessfully downloaded in step 114. In step 116, the player then looksfor a new Wi-Fi channel. When a channel is established with a new (orthe previous) server, the downloading of the song continues at the pointindicated by the marker.

In the description provided above, it was assumed that the song is beingdownloaded from a server through the Internet. Of course, as discussedpreviously, the source for the song may be another player.

The lists of songs for each player can be generated in a number ofdifferent ways. According to one feature of the invention, a recommendedlist is generated by the server, using various techniques, includingusing preferences of the user, monitoring the songs selected by theuser, monitoring songs selected by a group of users having similarprofiles and interests, etc.

A person downloads (or collects on the server) a large number of songsover a period of time. Because of this lag, the collection of songs mayinclude apparently duplicate entries. These entries may include actualduplicates, i.e., two or more exact copies of the same song, differentversions of the same song (the versions differing by the orchestraand/or artists, instrumentation, etc.) or may be two different songsthat merely share the same title but otherwise are completely different.Therefore, in the present invention, a catalog is created of all thesongs in a collection, by title, artist, producer or by using othercriteria. Songs with apparent duplicates are marked with a specificsymbol, such as an asterisk. For example, this additional informationmay include a listing of all the duplicates with an entry for eachduplicate indicating the artist and album, and/or other information.Preferably, the generation of the catalog of song entries and theindexing of all the songs used for generating the catalog is performedby the server. When a user selects a song with this symbol, a secondarywindow is presented with additional information that will enable theuser to determine what kind of duplicate is being stored. This processallows the user to select and play a selected song quickly and easilyeven if duplicates are present.

The process of displaying a catalog of songs can be used to allow a userto make a selection quickly and easily while minimizing computationaltime, especially in the hand-held device.

The songs available from a content provider are arranged in a masterdatabase. This master database can be searched using any criteria, suchas artist, title, album, genre, release date, and so on, using a knownsorting program. Each sort requires the server to send a sorted list ofIDs, reducing the required processing by the device to save on batterypower and reduce latency. The server prepares the data in a way thatother attributes can be quickly and easily shown to a user. For example,when an artist is found and albums are displayed, they are displayed inalphabetical order to make it easy to find a particular album. Albumsthat are most recently released by the artist are highlighted in bold orotherwise flagged for the user, so that the user can also quickly seethe most relevant and current material. Other indicators can be sent ina similar manner, such as data on “most popular” releases. A blockdiagram of device 10 showing elements required for handling lists in acatalog is shown in FIG. 1C. The elements are a logic module 704, a userinterface 706, a master listing of tracks available 708, a sorted viewof available tracks (“slice” files) 710, a file of duplicate titles 712,and an index of the files 714.

Feature 7—Handling New Lists

Once a recommended list is generated, the server presents this list tothe user. The user has the option to download the whole list or selectand listen to any or all the songs on the list. He can also receive onlyrepresentative clips from the list. Of course, all the other rules forbuying/playing/etc. songs are followed, including any DRM (DigitalRights Management) or other security rules. These rules may be requirethat the songs be copied only a predetermined number of times, during apredetermined time period, etc. If the user creates a playlist, orobtains a playlist from another source (e.g., another user's device orhis computer), or some other way, and the playlist refers to songs thatare not currently stored on the player, the player then automaticallyidentifies those songs and searches through its wireless and wiredconnections to either other devices and servers, direct point-to-pointor through a network. If the device finds a song that is on theplaylist, it will download it (in parts if necessary) from the first(or, preferably, best—such as one or more sources offering faster speed)available source, and will alert the user when the download is complete.The device sends an inquiry to other devices, identifying itself throughits unique user ID (validated in advance by a central server) andproviding the list of track IDs it is searching for (alternatively, thedevice can provide and compare the song name and/or other metadata tocheck for a match). The target device returns the list of availableitems it can provide, and then makes the file available for download bythe other device. This can take place through a proprietary or openprotocol, such as UPnP over WiFi.

In one embodiment of the invention, in addition to listening to varioussongs, a user can elect to transmit or broadcast one or more selectionsto the devices of other users. This feature may be accomplished, ofcourse, only if allowed by the DRM and other security means for theselections. Broadcasting is performed using standard streamingprotocols.

Another feature of the present invention is the predistribution of DRMlicenses. The content server 14 has a listing of all the songs that aparticular user orders or has ordered (or, preferably, is likely toorder, based on behaviors and preferences) but not yet received. When itbecomes evident that a song is about to become available, the serversends to each of the users the required DRM license. Therefore, once thesong is actually delivered to the users, the users can start listeningto, and enjoy the songs without having to wait for a license, even if acentral server is not present at the time. For a time-based subscriptionservice that offers “all you can eat,” each license would be valid forthe length of the renewing period or shorter, and would be renewedaccordingly only if the subscriber validly renewed the subscription.FIG. 1D shows a flow chart illustrating DRM license prefetching process.In step 802, the server compiles a list of the content ordered by theuser that has not been received or a list of preferences likely to beordered by the user. The device then contacts the server in step 804 andthen prefetches the DRM licenses but not the content in step 806. Instep 808, the user can then play back the content by applying theprefetch license once the device obtains the content file from the P2Pdevice in ad-hoc mode.

Feature 8—Connection to a Cellular Telephone Network

In one embodiment, a device constructed in accordance with thisinvention and identified as 10A in FIG. 3A includes a wireless chip 10Bsuch as GSM, CDMA, and/or TDMA (or broadband varieties, such as EDGE orEvDO) so that it can communicate with a common cellular network. In thisembodiment, the primary purpose of the device can either be a phone(with a music/video add-on) or a digital audio/video player (with anoptional phone add-on).

More particularly, referring to FIG. 3A, device 10A exchanges voicesignals and data with a cell phone base. The cell phone base 30 isconnected by landlines to a POTS 32 and through this connection providesstandard voice communication with other cell or land-based phones. Inaddition, the base 30 is also connected to an Internet gateway 34 andprovides Internet service (including e-mail, if desired) to device 10A.

In addition, the device 10A also includes an internal Wi-Fi (or otherbroadband wireless, such as Wi-Max) transceiver 10C through which thedevice 10A can communicate with the Wi-Fi gateway 36. Thus, device 10Acan access the Internet either through the Internet gateway 34 and cellphone base 30, or through the Wi-Fi gateway 36.

The system 100A is shown as including not only the network server 14with its content memory 16, but also a master content database 38.Database 38 is used as a depository for all the content available to thesubscribers of system 100A.

The advantage of system 100A is that the device 10A uses the optimalnetwork for connectivity dependent on the business and performancegoals. For example, to allow the user to perform searches for contentthat it is missing, the device 10A uses the cellular network throughbase 30 to contact the master content database 38. Since this is a fastbut limited throughput connection, the search results are returnedsubstantially instantaneously.

However, if the user decides to order a typically large file, such as avideo or audio file for download (e.g., as a result of the search),which are typically large files that consume a significant amount ofbandwidth for delivery (especially when compared to a normal voicetelephone call), the user can require that the device 10A only downloadthe content using a Wi-Fi network (as opposed to a 2G cellular networkor even a 2 1/2G, 3G or 4G network like EDGE or EvDO, which may implyhigher carriage charges), reducing the load on the cellular network forthe operator while providing ubiquitous search access for theuser—download access for the user would continue to require (or prefer)a Wi-Fi connection. Alternatively, the operator can offer the user thechoice to download the content over a ubiquitous wireless network likeEvDO instead of Wi-Fi, possibly for a premium price for the ubiquitousnature of the service when compared to Wi-Fi. In this laterconfiguration, the device can continue to execute all communications viathe Wi-Fi network when a Wi-Fi connection is available, but just makeuse of the cellular networks when a Wi-Fi connection is unavailable.

Feature 9—Sharing Playlists with Others

A system can be arranged so that new playlists are made, and the deviceautomatically downloads the new playlists and the associated content forthe user automatically. The user can specify the playlists by name(e.g., Party Mix #1) or type/genre (e.g., Rock Playlist #3), byselecting from a list that is made available on the device interface.Playlists can be sent just once to the device, or the playlists can benewly programmed periodically and automatically be sent down to thedevice. The device can add the new playlists to the collection on thedevice, so that a longer and longer list of content can be aggregated(which is preferably tied to memory reclaim logic, that deletes contentautomatically when a certain memory use threshold is exceeded for thistype of content) or can simply replace the previous content.

The user can choose which of these playlists he would like via thedevice interface, as previously described. In addition, the list ofavailable playlists can be made available on other devices, such as a PCusing a browser to visit the user's account on an Internet site. Thesite can reflect the status of the playlist orders stored for the user'saccount. So for example a user can browse the list of availableplaylists, decide to add Party Mix #1 to his account, and then thedevice will download the playlist and content automatically (eitherone-time or periodically, to the user's preference).

Further, the playlists can be programmed and common across all users, orthey can be customized to the tastes of the user, or acombination/hybrid approach. The tastes of the user can be captured invarious ways—ranging from monitoring the user's downloading and playingbehavior, to asking the user to state his genre or favorite artistpreferences, to established and new collaborative filtering techniques,and other ways—and these tastes can then be used to generate a playlistof customized songs, relying on a database that associates the user'stastes with particular content (e.g., through Bayesian statistical meansgiven a large enough population of users, human intervention, or othermeans or combinations of means). The length of the customized playlistmay be specified by the user. The periodicity of delivering the playlistto the user may be specified as well. The playlist may be downloadedand/or made available via streaming or download (in which case,preferably incorporating progressive playback capability, so users haveinstant playback access after the start of the download) through avariety of devices owned by the user, including the Wi-Fi portabledevice (where content downloads automatically to the device—as thedevice polls the back-end to check for new updates frequently) or any ofthe user's PCs. Digital rights management technology can further beemployed in connection with the content and the devices to ensure thatthe content in the playlists is respected accordingly.

Feature 10—Making Selections from Playlists

Generally speaking, lists can be generated by a user in many differentways. One simple and straightforward way is to present to a user all theselections available from a content provider. The user can then pick andchoose each selection individually, or select a plurality of songs basedon specific criteria. Another method is to have the user provide theserver with a profile that includes his preferences/dislikes. The servercan then use the profile to make selections from a master list. Anotherway is to have the server present to a user generic lists, such as listsof featured songs generated at certain times, songs by particularartists, etc., lists of songs that are most downloaded, based oncriteria such as overall popularity, age of users requesting aselection, physical location of the user, profession, income etc. FIG.1E shows a flow chart of users receiving recommended lists of musicalselections. In step 902, the devices compiles the user's preferencesbased on inputs by the user and based on the user's actions (e.g.,deletions, most played songs, etc.). The device then transmits userinformation to the server using a device specific ID in step 904. Fromthe information, the server generates playlists for the user in step906. The device then contacts the server for an update in step 908. Ifthere are new recommendations (step 910), the server makes the contenton the list available to the device in step 912 which is then downloadedand made available to the user in step 914.

The selections on a list presented to a user may also be based on moresophisticated criteria. For example, it may be selected based on dataabout the user's preferences and profile which may be obtained based onstatistical cross-referencing (e.g., Bayesian statistics), throughcollaborative filtering, through compiling of the user's manual ratings,and/or through monitoring of the user's listening and downloadingactivity, or in a plethora of other ways, the server compiles a list ofrecommended content. The server then personalizes the content and sendsa recommended list, plus the content files, to the device. The contentmay be protected in such a way that the content times out and thereforecan only be used for promotional purposes. Or it may be permanentcontent, or delivered pursuant to a subscription service, or other model(e.g., “DMCA compliant” offline playback, which ensures users can'trewind songs, can't see the upcoming song selections in a playlist aheadof time, are limited in the number of skips, etc., per the DigitalMillennium Copyright Act non-interactive streaming requirements). Inthis way, the user is provided with “customized radio” playlists thatcan be controlled (or, if preferred, hidden and restricted to the extentand/or until one or more conditions are met) from the user.

Feature 11—Sharing of Playlists by the Same User on Different Devices

In one embodiment, a user uploads content to a server to a “storagelocker in the sky.” This server could be the server shown in FIG. 1, ora different server. The server can be a commercial service or free,provided it can uniquely identify the user, for example through a secureuser ID and password.

The user can then access that content—either by downloading a cleartextcopy of the file, a DRM-protected copy of the file (the content filecould be DRM packaged as soon as it is uploaded to the server and storedin encrypted form, or alternatively encrypted on the fly), or bystreaming a copy of the file (e.g., over a protocol like RTSP, or via aprogressive downloading scheme).

This allows the user to use distributed storage to store his/her media.It allows for content owners to ensure the content is not widelydistributed from the central server.

The user can then access the content from a multiplicity of places andthrough a multiplicity of devices, provided the user's accountinformation can be conveyed and authenticated by the server. The servercan limit the number of simultaneous connections for security reasons.Preferably, a user should be able to access his information only from alimited number of locations/devices.

When the user purchases content from a digital store, a copy of thecontent can automatically be deposited into the user's storage locker onthe server.

Feature 12—Displaying Cover Art and Other Information on a SmallDisplay.

A problem encountered in designing a small portable digital audio deviceis displaying relevant adequate information for a user during playback.For a music selection in particular, a user may wish to view the albumcover art, the song title, the album title, the artist name, theplaylist name, and other relevant information about the selection.However, a small screen may not permit displaying the cover art in alarge and pleasing size for an average user while also displaying thismetadata information in a large enough size for average users tocomfortably read. Further, it is desirable to display this informationfor users without requiring the users to take manual actions. To addressthis, the cover art and other information can be made to cycleautomatically from one screen to another, so that one screen fades orotherwise transitions from one screen to the other at periodicintervals. This allows the user to see the cover art and also otherinformation (such as song name, artist name, album title, etc.) withouthaving to manually make selections or push buttons. In one embodiment,the cover art is sent to the devices in a standard size and the devicehandles gif or jpeg resizing depending on the desired display. The imageis stored in one size by the device, and delivered in only one size. Inan alternate solution that supports multiple device classes involvestranscoding (either on-the-fly or in advance), so the server determinesthe appropriate (i.e., highest resolution) size art based on the classof device that is making a request, and then sends the appropriate fileon through. The device can then re-size the image down, but not upunless the image is degraded.

Feature 13—Messages to the Users

According to one feature of the invention, whenever a user contacts theserver through his player, the server sends information to the playeradding or deleting entries such as the recommended or featured lists, anupdated list for the user, and so on. This information is then displayedto the user. The server may present to the user other information,including messages from the billing department, etc. These messages canbe presented as pop-screens, entries in an IN BOX, etc. Other entriespresented to the user may include new or changed terms of service, othercommercial products or services (including discounted or enhancedservices) available from the server, and so on. Various services may beprovided to the user, either on a per use basis, a la carte (e.g., thedisplay shows items selected by the user during the set-up of theplayer), or on a default basis.

The system can be further configured to enable an administrator on aback-end server to specify particular places in the user interface of aportable or other device that connects directly to a network, and tocustomize the text and graphics displayed at those places as well as theoptions and interactivity offered to a user. For example, theadministrator can specify that a popup should appear for the user every3rd time the device is powered on, and the popup should rotate through15 different messages selected at random (e.g., intriguing blurbs whichcapture the attention of the user, or relevant advertising messages).This is done via an automated procedure in the device software, whichinquires of the server for a file to display for the user. The filespecifies the location, conditions and content to be displayed to theuser. It also lists the choices and specifies the actions that are takenwhen a user selects a particular item.

Feature 14—Transferring Content Between Devices

The transfer of content to portable devices is performed on a one-to-onebasis from server 14 (as depicted in FIG. 1) to all the devices of thesystem, such as device 10 using standard protocols. However, content canbe distributed by other means as well. One alternate means includesstreaming content already stored on one portable device either toanother portable device, or to many different devices. Thetransmission/media file could be secured or unsecured. Another alternatemeans is to receive content from a source, such as the server shown inFIG. 1 and to simultaneously stream it to one or more devices (or,depending on whether it would be desirable for the content to bepersisted or to buffer against dropouts, to use a progressivedownloading scheme). One device could access the content of anotherdevice (either via streaming or progressive downloading, whether securedor not) by having the devices connect, say via an ad hoc Wi-Fi link, andcommunicate, say over a UPnP framework, and to use a common downloadingor streaming protocol to enable the playback, e.g. via HTTP in aclient-server fashion. Yet another means of distributing content is tohave it distributed in pieces using a P2P file sharing protocol—e.g.,multiple devices connected to one another via a Wi-Fi ad hoc link couldshare files in pieces (e.g., technique employed by Bit Torrent), so thata single device is simultaneously sourcing different pieces of the samefile from multiple other devices in a multi-threaded fashion, and thenassembling the file into an integrated whole as the pieces aredownloaded.

Feature 15—Content Distribution Using Bit Torrent

In the embodiments described so far, content was delivered to a playerfrom a single source (that could be the server 14, or another player ordevice) using a standard network communication protocol, by streaming,or using a P2P protocol. Yet another alternative is to use a BitTorrent-type protocol wherein different portions of content (forexample, different portions of a song) are received from differentsources. FIG. 1F shows a combined flow chart and block diagram of anexample of a P2P file sharing protocol across wireless portable devices.In step 1002, the devices are linked by wireless connections. Device Athen seeks a copy of File X (step 1004) by sending an inquiry about FileX to Device B (step 1006); Device B has compiled and stored an IndexFile, listing the files that area available for sharing by all otherdevices in its network (step 1006). Device A is informed by Device Bthat Devices C, D, and E have copies of File X in step 1010. In step1012, different portions of File X begin downloading to Device A fromDevices C, D, and E in a multithreaded fashion tagged to indicate itsorigin. Optionally, in step 1014, Device A's optimization softwareanalyzes the speed and connection quality of the transfer, which is thenadjusted to optimize performance in step 1016. Finally in step 1018, anintegrated complete copy of File X is assembled by the software ofDevice A.

In this way, multiple devices connected to one another via a Wi-Fi adhoc link could share files in pieces (e.g., technique employed by BitTorrent), so that a single device is simultaneously sourcing differentpieces of the same file from multiple other devices in a multi-threadedfashion, and then assembling the file into an integrated whole as thepieces are downloaded. The pieces are coordinated via the use of anaccompanying tracker file, which describes how the content file can bebroken down into pieces. This allows for the receiving device to “map”the pieces and reassemble them into the proper order. The breaking upinto pieces and development of the tracker file can be accomplished by aserver in the network, or by a node/user in the network which is chosenmanually (or, preferably, automatically based on characteristics such asupload speed and reliability of connection) to serve this role.

Feature 16—Exchanging Voice Messages Between Users

It is common for mobile wireless device users to create and record textmessages which are then transmitted to one or more other recipients(which are generally also using wireless mobile devices but also who maybe using, for example, a PC connected to the Internet to retrievemessages), such as via a SMS (Short Messaging Service) protocol. It isalso common for users to leave voicemails for other users, where arecording is created by a machine attached to the recipient's phone lineor which is provided at the network level by a phone or data serviceprovider of the user. However, mobile wireless users today do not haveready access to an easy way to create an audio recording stored on thesender's device (say a recording of the sender's voice), and then tohave it transferred to one or more preferred recipients. If the playerincludes a microphone, or a microphone input, the user can record ashort audio message and send it to another player when both areconnected to each other directly (in the ad hoc mode) or indirectly (viathe Internet). In a preferred embodiment, a single push button on theplayer is used to provide this function. The messages can be sent usingan IM (Instant Messaging) protocol capable of file attachments/transfer,or any other file transfer protocol capable of transmitting a copy ofthe audio file (or rendered audio) to the receiving device. Optionally,the user can also insert a music clip into the message, which mayfurther be optionally mixed on the sending device into a single filewith the user's recording (preferably, at the time it is being recorded,but alternatively afterwards) so that it serves as background sound(volume reduced) with the user's voice on top. (Alternatively, two ormore distinct audio files could be transmitted to the receiving device,optionally with mixing information such as offset timing for start,relative volumes, etc., and the receiving device can be made responsiblefor mixing these two audio outputs, either in a process prior torendering that creates an integrated audio file or during rendering.)Any compressed or uncompressed format (secured or unsecured) capable ofbeing ultimately rendered into an analog audio output is acceptable,though compressed formats are preferred to reduce transfer time andstorage space. The recipients' mobile devices provide an alert when sucha new message is received. The recipients may be members of a buddylist, a chat room, names on an address list, etc. or may be strangerswho detect each other's players over the wireless connection. Morespecifically, a user can record an oral message using a device (e.g., aportable Wi-Fi player). The device allows for a source (such as amicrophone or line-in input), and uses a traditional digital encoder toallow users to create a digital recording (e.g., MP3 or WMA encoder).The recordings can then be sent to other users (e.g., through the Wi-Fion the device, either directly peer-to-peer or through a serviceoperator's central servers via the Internet, using its buddy system andcommunity/messaging system). Audio files can immediately be sent toother online users and users connected peer-to-peer. Optionally, theycan be cached by a central server and delivered to a device the nexttime it connects. There are several means for implementing this feature.In one implementation, a user selects a “buddy” from a list of existingbuddies, as well as a list the device compiles from availablepeer-to-peer users (e.g., in ad hoc range for a Wi-Fi device) orpresents a list from the central server (e.g., per the “chat room”approach described elsewhere). On selecting the buddy, the user isprompted to record the message as an audio file. The recording is madeand stored locally on the device. The user uses traditional controls tostart and stop, and if required re-record, the audio file. On confirm,the user can then send it to one or more desired recipients. Optionally,the device can be used to select several recipients at a time (e.g., viaa pre-defined group, by making multiple selections of individualbuddies, by selecting from automated groupings such as “all my buddies”or “my friends”, by selecting from groupings compiled on the centralserver such as “all jazz enthusiasts”), and then send the same file tothose multiple user devices simultaneously (e.g., through a Wi-Fibroadcast locally, point-to-point, or through a central server, whichmay optionally cache the file for users who are not currently online).Users can also optionally select buddies while they are using a devicethat is not connected to the network, and the device can store/cache thefile and the list of target buddies until such time as the deviceconnects either to a network or the target buddies in a peer-to-peerfashion, at which point the file is sent automatically.

FIG. 1G shows a flow chart of audio file transmissions between buddies.For this purpose, the user records the audio file in step 1102. Then,the device presents the user with an option to “beam” the recording toone or more buddies in step 1104. The audio file is transmitted (i.e., acopy is recorded by the receiving device) to the other buddies asdescribed as shown in FIG. 1G step 1110. If no connection is availablein step 1106 or the recipient is not available in step 1108, the requestis cached in steps 1112 and 1114, respectively.

The recording may be streamed from the device to the other users (again,either peer-to-peer (through a network or directly point-to-point) orthrough a central server). Accordingly, as the recording is beingcreated it is simultaneously transmitted by the device to the otherusers. The receiving device(s) may optionally store the file permanently(or subject to DRM-enforced usage rights, which would be encoded on thetransmitting device (or optionally by the central server)) or may notcapture a copy of the file, in all cases described above. In all of theabove scenarios, if the sending device permits video to be captured orstored, video may optionally be used in place of, or together with,audio.

Feature 17—Managing Playlists on Small Screen

Portable multimedia devices such as MP3 players typically have limitedsized displays. A typical screen is black-and-while or color LCD with128×160 pixels and is 1.6″ wide, but more recently ranging up to QVGA oreven VGA and a screen of 3.5″ or larger, to enable a portable formfactor for the device, and easy and convenient carrying, especially in apocket. The devices also typically do not have an alphabetic or numerickeypad, but rather are limited only to a 4-way control and possibly a“select” or “enter” button. This arrangement makes the entry andmanagement of large media collections difficult without the use ofanother machine, such as a PC, that offers a larger screen and morerobust I/O, such as a full-size keyboard.

The present inventors have developed an arrangement through which, usinglimited controls, the user can easily create new playlists, name andre-name playlists, add songs, albums and other playlists to playlists,delete items from playlists, and re-order items on playlists, even witha limited sized display. More broadly, this arrangement also allowsentering text on a device that has limited I/O options. This feature orarrangement operates by providing several screens logicallyinterconnected with each other.

Initially, the user is presented on a screen with a plurality of optionsor choices. Selecting one of these options causes an associated newscreen to be displayed. For example, to create a new playlist, the userselects a “create new playlist” option, and is taken to a second screen(which may or may not be a “popup box”) that displays a number of blankcharacter spaces, with a cursor indicated in the first character space.If the user selects the Up or Down key, the character under the cursorchanges accordingly, sequentially from A-Z or from Z-A (with numbersand/or special characters, and potentially lower-case letters, cyclingthrough in turn), as the case may be. Once the user finds the desiredletter by “spinning” the letters in this fashion, the Right key advancesto the next character space. The user continues to do this until thefull desired name of the playlist is spelled out. The Left key operatesas a back-space key, deleting the previous character. Alternatively, theLeft key can simply move the cursor without deleting any characters.

To rename a playlist, the user selects a “rename playlist” option and istaken to a screen that displays the current name of the playlist, withthe cursor located at one character space after the name. The user canhold the Left key for a specified time to clear all letters and returnthe cursor to the first position. Alternatively, the user can press theLeft key quickly to delete characters, and/or can add characters asdescribed in the foregoing paragraph.

To add a song, album or playlist to a named playlist, the user pressesthe Right key while the cursor or highlighter is located on the desireditem to add. A list of options is shown to the user, including one thatis “Add to a Playlist”. (If this option is listed first among all otheroptions, it makes the addition of items even simpler and quicker for theend-user.) If the user selects this option, the user is then shown alist of existing playlist names (and possibly the option to “Create aNew Playlist”). If a playlist is not yet named, the user can be promptedto do so after requesting that an item be added to a playlist. Once theuser selects a playlist from the list, the item is then immediatelyadded to the playlist. The playlist may take any form of database andmay use any form of identification of the items, such as file name or IDnumber (potentially embedded in the header of the content file itself).The items are added to the end of the playlist, which maintains aconsistent order. The playlist may use a standard file type, such as.M3U, or may use a proprietary one.

The playlist to which items were most recently added are displayed atthe top of the list, making the most-used playlists the most accessibleones to the user. Accordingly, by pressing Right three times on an item,the user can quickly and easily add that item to the most recentlyadded-to playlist. FIG. 1H shows this scheme for adding a song to aplaylist; In step 1202, the user presses the Right key while Song 1 ishighlighted. In step 1204, the user then presses the right key to choosethe “Add To Playlist” option. A list of playlists are displayed in step1206 and the user presses the Right key to add the song to the selectedplaylist. The user is then returned back to the original “My Songs” menuin step 1208.

Once items are added to a playlist, the user may edit the order of theplaylist. This can be accomplished by pressing the Right key on any songor other item listed in the playlist and selecting “Move this itemUp/Down.” When selected, the item is highlighted for the user (e.g., itmay be displayed in inverse color, or with a different color backgroundor in a different font). During that time, if the user presses Up orDown the item moves in the order of the list accordingly. The LCDdisplays items that are immediately under and/or above the selecteditem. When the user finds the desired place for the item, the userpresses the Select button and exits this mode. The playlist may storethis re-ordering information only on pressing Select after the finalpositioning, or alternatively each time the item is moved in the listupon the user's pressing Up or Down.

Feature 18—Sharing Content

Users of digital content seek ways to obtain access to new content aseasily as possible, from the first available source of content. Also,given the large amount of electronic content available in today's world,users also benefit from a way that they can find content which is likelyto be more appealing and/or relevant to them. One additional way ofdiscovering new content is through a collaborative filtering method,wherein data and recommendations from other peers are used to provideone or more recommended content selections for the user.

Content owners also seek ways to ensure control over their digitalcontent without overstepping on the digital capabilities offered to theend-users. A device (portable, such as an MP3 player, or otherwise) thatis capable of connecting to a network (such as the Internet) and server,would allow for the following:

The device is capable of storing media, and/or of streaming anddownloading media content from another electronic source (e.g., overUPnP and/or RTSP). Media can include music, video, and photos, and alsoany other type of electronic file such as e-mails, voicemails,spreadsheet files, word processing documents and text, and other data.

When connected to the network (e.g., the Internet), the device contactsa central server. The central server allows the user to manage a list of“buddies” that the user maintains via the interface on the device oranother interface. When the device is identified to the central server,the central server sends back current (or the latest available cached)information on the user's buddies' devices. For example, it may send thecurrent user ID of the buddy and the current media selection (e.g.,song) playing on that device. The device can then display thisinformation to the user of the device, and optionally update it in realtime if the buddy is currently online. In addition, the user can insteadfind other users randomly through the use of “chat rooms”, wherein theserver sends a listing of currently available chat rooms to the deviceand the user selects an available chat room to enter. Once in the chatroom, the user sees the same information, and is offered the samefunctionality (described more below), as though the other users werecurrent “buddies”.

Further, the user can select a particular other user and choose tointeract with that user. In this event, the server compiles a listing ofthe available content files on the other user's device (users mayoptionally be given the right to hide particular files, or allow them tobe seen but prevent them from being shared—this information is stored onthe central server when changed and/or the device and used to filter thecontent listing that is compiled and sent). The listing may be in aparticular order that is useful for searching and browsing, such as mostrecently acquired files in reverse chronological order, most frequentlyplayed, or alphabetic order. This order may be preserved in the transferof the listing to the device. Each listed item may come with metadata,for example whether a particular item may be downloaded and copiedbecause the content rights holder has granted permission for thisactivity. The metadata may also specify the conditions for the sharing,such as for example a song may only be played twice by the recipient andthen times out, or the song may not be re-transferred to another device.The recipient device enforces these rights against the user through theappropriate DRM rules. The listing information pertaining to the otheruser may be displayed to the user of the device. If the user identifiesan item that is of interest, the user may select it, in which case thedevice contacts the server. The server then may either provide an IPaddress (or equivalent for a non-IP network) where the device mayconnect and (subject to conditions, if specified) download or stream acopy of the file, dependent on the rights applicable for that particularitem. A content rights holder may be given the right to specify thatcontent not be downloaded in any way, but only streamed (requiring thesecond device to be online and connected during the playback, andpreventing additional copies from being made while enabling users to tryout a sampling of the content). In addition, a system that managescontent rights can check whether the content indicated on the listingcame from a verified source of content (such as, for example, acommercial digital music store operated in tandem with the centralserver that marks each file with a recognizable content ID), and offeronly streaming rights (and no, or limited, download rights) for contentthat does not match content in the central server. Further, alternatemethods such as audio and video “fingerprinting” can be used to verifythe content of the file.

When the user selects a file, streaming (if permitted according to therights enforced by the central server) may be initiated over any of amultitude of known protocols (e.g., RTSP) or over a proprietarystreaming protocol. In addition, a downloading protocol can be utilized(e.g., via UPnP) wherein the recipient device enforces a streaming-likeexperience by, for example, (1) downloading the file and playing it backprogressively as the download continues, (2) checking periodicallyduring playback to ensure the transmitting device is stillelectronically connected and/or present, and (3) deleting the contentfile when finished to prevent the end-user from accessing it at a laterpoint. The file may be encrypted or not encrypted-if encrypted, therecipient device needs to obtain information for decryption eitherduring or in advance of the transmission from the transmitting device,or during the transfer or in advance from another source (such as thecentral server). When the user selects an item for download (as opposedto streaming), and the download is permitted, the device can use any ofa multitude of known protocols for the download (e.g., via UPnP) or aproprietary protocol for the transfer. Upon receipt, the file can beencrypted or non-encrypted. If it is encrypted, the recipient deviceneeds information to decrypt the file, either during or in advance ofthe transmission from the other device or from another source (such asthe central server). This decryption information may be, for example, aDRM license file. The central server may, for example, pre-deliver DRMlicenses as appropriate, say to paying subscribers of a server,obviating the need to check in with a central server upon or after thereceipt of new DRM-protected content.

The system may also provide that specified content may not be streamedor downloaded in any way between devices.

The listing maintained by the server described above may optionally bereplaced by a system whereby the listings are compiled and maintained ona distributed basis by end-users, which is a common architecture usedfor other peer-to-peer systems in place today. In addition, the rightsoffered in conjunction with each piece of content may be maintained withthese listings, though a requirement that either the listing device orthe recipient device is required to check in with a verified centralserver enhances the security of the system. Other actions of the centralserver may also be handled in this distributed fashion as well.

The devices are able to enforce these rules in accordance with theoperators of the system by one or more of the following means:

maintaining secure software code in the kernel device, or otherwiseensuring secure software code is running on the device (e.g., via signedcode techniques);

including a secure digital rights management technology in the softwareand/or hardware on the device;

taking steps to prevent or inhibit non-permitted software to run on thedevice and, in particular, access the content files and be able torender them or transfer them; taking steps to prevent or inhibitnon-permitted hardware devices to be used to tamper with the protectionsoffered on the device, such as by eliminating points where an electronictool can be easily inserted across an electronic storage device and CPUto intercept electronic signals (e.g., to reverse engineer a process orbreak an encryption scheme); building devices as standalone devices witha defined set of functionality, which contrasts with, for example, ageneral purpose PC where users are generally invited to load newsoftware onto the device and to access content on that device; includingin these devices a way to connect directly to the network, such asthrough a Wi-Fi chipset; providing for a method of securely updating thesoftware and firmware on the device, such as through signed code sent tothe device (automatically or manually at the request of a user) viaWi-Fi (for example); including in the software on the devices code thatis receptive to conditions associated with particular items of contentsent to the device, some of which may be included in the DRM but some ofwhich may not, such as “this song may only be sent to 3 other devices,”in which case the device maintains a count of transfers of thatparticular content item to other devices and then prevents furthertransfers of the content when the count reaches the specified maximumnumber of transfers.

Feature 19—Hot Spot Without Browser

The device can connect to Wi-Fi access points and the Internet without abrowser as previously described. In some cases, a public Wi-Fi accesspoint operator/provider will install software that does not permit usersto access the Internet unless certain conditions are fulfilled. Anexample is a public Wi-Fi “hot spot” provider who requires that userspay for access to the Internet via its access point, such as T-Mobile,and accordingly uses software that redirects any device which connectsto the access point and attempts to connect to the Internet to a “splashpage” that requires the user to enter credentials—such as a username andpassword—before Internet access will be permitted. In some cases thissort of “splash page” is not used in connection with a pay network, butone available for free; it nevertheless may require the user to click ona button via a browser or take some other action to be admitted access.The back-and-forth communications between the user via the browser andthe software/service, referred to as the “script”, need to have beencompleted before access is provided.

Once access is permitted by a provider (e.g., because an action is takenby the user and/or credentials are verified against a back-end server),access can be openly permitted to the device. This may beenforced/arranged via a variety of methods, such as MAC addressfiltering.

To enable a user to connect that the wide variety of public Wi-Finetworks via a device that does not include a browser is a significantongoing challenge. The present invention addresses this as follows:

Software code on the device, which may or may not include a browser, canbe written to address the script. The back-and-forth communications(e.g. handling a “wrong password” message to a “click here to continue”message) can be received by the device and communicated to the accesspoint (or software, wherever it may reside, including on a server) bythe device by simulating the output of a typical browser for the accesspoint. This would accordingly replicate the digital output that manualactions of a user on a browser would be sending.

The device can provide an interface for the user to enter and store anycredentials that are required for access to credential-based networkssuch as T-Mobile®R Wi-Fi hot spots, as indicated in the flow chart ofFIG. 1I. As shown in FIG. 1I, the device attempts a connection to aWi-Fi access point in step 1402. If a loading screen blocking freeInternet access, a splash page, does not appear in step 1404, the deviceconnects to the Internet in step 1408. If a splash page appears, in step1406, the device stores a copy of the splash page as a file and then instep 1410, the device connects to Internet and sends the splash page andconnection data to the server. The splash page is then identified and ascript is written to allow the user to enter logon information. In step1412, all devices are sent logon scripts from the server. In step 1414,the user then enters necessary logon information and connects to theInternet.

The script of a network can be analyzed by an engineer to diagram/listall the back-and-forth communications that are required for a logon tothe network or to otherwise provide access. This analysis is used todevelop the code that replicates the required communications output forthe software/service serving to block access.

To manage the increasing and changing number of various access pointconnections, users of the devices are used to collect information on therequired scripts. Because the device they carry connects to the Internetat least periodically, it is capable of sending and receivinginformation. When the device encounters a script that it is incapable ofparsing to access the Internet, it can then store a complete record ofthe communications and/or “splash page” that prevented this access. Thisinformation can then later be communicated over the Internet back to anengineer (preferably sent automatically by the device), who can thendevelop a new script for communicating with that particular accesspoint. When the new script is developed in software for the device, thisnew software can then be sent back to the device and installed so thatit can then gain access at the problem access point the next time

This system can be replicated across hundreds, thousands, or millions ofdevices or more. With many users in the field encountering thesenetworks, collecting information, and sending it back to a centralback-end repository, one or more engineers can use this capturedinformation to create software that replicates the needs of anyparticular script and then send out this new software to all devices inthe field. In this fashion support for a wide variety of Wi-Fi networkswithout a browser can be provided, with few requirements of anon-technical user, and even in the face of access points that changetheir logon methods and scripts over time.

Feature 20—Telephone-Based Music Service

Another feature of this invention is that a user can download or streamcontent from a server using a telephone connection. FIG. 1J shows a flowchart for downloading a song to a device through a telephone and FIG. 1Kis a block diagram of the system used to download songs. The systemincludes one or more servers 1512 holding user information and content(songs), an IVR system 1514, a POTS or mobile central telephone system1516 that is accessible through a mobile or other telephone 1518. A userdials telephone number from telephone 1518 (preferably a toll freenumber) in step 1502. The rest of operation can occur automatically ormanually. For automatic operation, a recorded voice (using IVR system1518) asks the user if he would like to listen to radio, his personalcollection, or find a new song in step 1504. If he wants a newsong/album, he chooses to search by artist, by album, or by track (orother ways) in step 1506. He says the name, which is voice-recognized,and then can narrow in on his desired item. (Alternatively, a touch-tonemenu driven hierarchy can be used. This is preferable where the voicerecognition software is not advanced enough to handle the large numberof possible human responses, and/or where the user would prefer to usebuttons to make a selection based on accuracy, speed and convenience ofnot having to disturb others who may be around him/her.) In step 1508,the IVR system 1514 then queries the server 1512 to verify the useraccount. The server 1512 then calls up that item from a digitaldatabase. The request starts playing it over the phone, streaming in anappropriate bandwidth-matched compressed format or simply rendering itas analog audio in step 1510.

Feature 21—New Album Indicator

Previous devices typically included a display (such as an LCD display)on which a user could selectively obtain information of variousselections available for listening and/or other functions, using arelatively simple user interface. Referring to FIG. 3, a catalog system200 in accordance with this invention consists of a server-sidecomponent, the intermediary server system 210. This component collectsand aggregates a list of new releases of available content from variousexternal content providers 202 (e.g., recorded music albums which havebeen digitized to a compatible format, relevant metadata fields for eachrecord, for such an album, the recording artist, the title of the album,the year of publication, the genre, art work etc.), which may beconnected to the intermediary servers 210 over the Internet 212. (Ofcourse, the operator of the intermediary server 210 can also opt tooperate the external content provider 202, rather than rely on externalsources, or may use a hybrid approach.) The intermediary server 210 usesthis data to generate and update the listing of all available contentfor various users. A selected subset of the content is stored in localdatabases on end-user devices 204, 206, 208 in the field. The databaseon each end-user device 204-208 allows users to search for and ordercontent even while their respective devices do not have an activeconnection to a network, and with less latency than a search requiring aquery of, and response by, a server over a connection. A database may,for example, store the listing/metadata for 3+ million available musicaltracks, albums, etc. or videos that are available for download from acommercial digital content service or content provider.

The new data is then passed to and handled by an intermediary serversystem 210 performing a “delta file” process. This process has as anoutput a series of incremental file updates that are stored on theintermediary server 210, each of which is intended to provide an updatefor a particular previous update version of the catalog (i.e.,representing the differences/changes between a fully updated catalog andone that is not yet updated). This allows each of the end-user devices204-208 to access the intermediary processor 210 and obtain a versionnumber or last update time for its local catalog database (e.g., adevice which was updated last month and missed 5 intervening catalogupdates might indicate a version number of 25, while the currentupdated/available version is 30) and request a single update file whichis perfectly matched to bring the catalog fully up to date. The updatefile includes only the incremental changes (i.e., additions, amends, anddeletions) that are needed to update the device's existing, older storedcatalog to the current version. Once a device, e.g. 208 is made awarethat an update is available, it downloads the single update file (which,to increase download speed and reduce size, may preferably becompressed) from the intermediary server 210, and then runs an internalprocess which updates this catalog, inserting new records and deletingor amending old/existing records, resulting in a fully updated catalogthat the user can then search, which would include the latest albumreleases. Alternatively, the delta process may determine that it is moreefficient to send an entire new image of the database (or portionthereof) rather than an incremental update. Finally, the delta processin processor 210 may determine that a device catalog is damaged andneeds to be completely replaced. These update files (whether incrementalonly or complete catalog replacement) may also alternatively includeinformation that specifies how all or portions of the complete updatedcatalog are displayed to the user through the user interface. In otherwords a “slice file” may be incorporated representing an update to aparticular catalog (e.g., a list of the Top 10 track IDs). Therespective device, e.g. 208 then will display these specified tracks tothe user under a “Top 10” item located in the user interface, allowingthe user to see recommended tracks, etc. in addition to searching forany of the available content individually, and to order those tracksindividually or as a whole collection).

The server-side component 210 stores a number of updates dating back toa reasonable point—for example, any device that has a version number ordate that is within 6 months old. (Preferably depending on server side,a minimum version number is selected which optimizes the desired storagespace that is available for this process on the server side, as well asthe trade-off between the device's performance in downloading andupdating an incremental update file instead of the full catalog as a100% replacement.) The server-side component 210 has a code whichdelivers the appropriate update file (created and stored on theprocessor 210. or other servers) to an end-user device 208 dependingupon the version number the end-user device 208 provides. If theend-user device provides a version number is that is below the minimum,the processor or server 210 provides a database file which consists of100% of the updated catalog, as a complete replacement for the existinglocal database on the device. If the version number is above theminimum, it provides an appropriate update file for download that thedevice can then process.

The process described above is advantageous in that it provides a singleupdate file to devices which may not have continuous, “always on”connections to a network 212. It provides a rapid and efficient way fordevices which may have a variety of “last points/times of contact” withthe network to be brought up to date for the end user, opportunisticallywhenever the device is able to establish a connection. (Depending onlocal storage availability (e.g., if the device is designed to keep twocopies of the catalog so that one may be updated while the other is usedfor searching by the user) and the method of update on the device, thecatalog may not be searchable by the user during the period the deviceis processing an update. An appropriate message may be shown to the userat that time, if the user attempts to search.)

Preferably the system is constructed in a way that permits the operatorsof the server to dynamically control what portions of the totalavailable catalog, if not all, are made available via this replicationand updating process—for example, for a device that has memoryconstraints, perhaps it would be desirable that only the top 10,000tracks of the catalog be searchable via this method, and that users berequired to search via a live connection for any others, in a hybridapproach. For devices with constrained memory, it is preferable that theapproach be a hybrid one that combines the on-device catalog systemdescribed above with “live searching” across an active connection to anetwork and server-side system. In this way, the system balances theconstraints of limited memory against providing relevant search/browseresults to the user with limited latency, and with reduced reliance on anetwork connection, when available. Any of several methods for selectingwhich content titles should be included in the partial on-board catalogcan be used—preferably a method is chosen that provides the greatestchance the user will search those titles so that a search against theservers is as unlikely as possible. For example, the system mightmonitor the downloading behavior and other preferences of a user—if theuser, for example, indicates that he/she likes jazz, the top 10,000 jazztracks from the service might be provided, since it is more likely thatthese tracks will be the ones that user would like to search. Or if auser has downloaded music from the artist Charlie Parker (or, e.g.,video movies from Spike Lee) but otherwise has a lot of 80's music, thesystem might provide that user's device with a catalog that includes allthe works of Charlie Parker but otherwise 80's music-oriented selections(or, for the video example, all of Spike Lee's movies, plus a listing ofthe other videos that more generally comport with the user's mediaconsumption preferences and tastes). The system preferably pre-packagesand stores these files for the end user devices to download in advance,so that it minimizes latency during the time the device is connecting tothe network to obtain updates, and so that it optimizes other aspects ofthe system and servers, but alternatively these custom catalogs forend-user devices can be constructed “on-the-fly” in any degree ofdesired granularity—i.e., record-by-record for maximum granularity, oralternatively from “building blocks” that are pre-built and successivelysent as updates (or catalog replacements) to the device. In the exampleabove, for example, the user might get the 80's music “building block”plus other relevant areas of the catalog. This balances the pre-buildingoptimizations (e.g., storage on the server-side system) with a higherdegree of customization for an individual user device.

In addition, the operators of the server would preferably maintain theability to dynamically change how the category of files appears to theuser on the user interface, such that a “slice file” may list the “Top10 Hits” one week, and the next week this may be changed to read“Favorite Summer Songs.” The slice file would list the songs that shouldthen appear when then user selects this item. The text that shouldappear in the user interface would accordingly be preferablycommunicated, at minimum, each time that the operators desire the titleof the category to change. This can be achieved in multiple ways,preferably through a framework approach wherein the user interface ofthe device will respond to data that can dynamically adjust thestructure of the user interface without requiring a re-boot of thedevice, including allowing the data to reconfigure the levels of treesin the menu structure, creating nested options, etc. Alternatively, amore simple and limited approach, which is preferable if simplicity isimportant, would designate certain elements of the user interface to bedynamic (e.g., the title of the menu option under a “Get New Music”option, as shown on display 214), but require other elements to remainrigid (e.g., the menu item must include only one layer underneath, whichmust consist of a listing of tracks, not albums or artists).

Any number of variations and improvements to the above process arepossible. In one particular variation, it is desired to indicate to theuser through the end-user device user interface which titles are new, sothat new material can more easily be found. To achieve this, the updatefile can preferably include a “date of release” metadata item for anydesired record (e.g., a musical album) where this information would beuseful. The user interface of the device can then use rules indisplaying the listing of albums for a particular musical artist whichplace a “NEW” icon next to the items that had release dates that are,say, within three months of the current date at the time the device isbeing used. This is a preferable method, though other methods mightinvolve the update files themselves indicating a 0/1 bit setting forwhether a particular item in the database should be signified to theuser as “NEW”. (This method would not work appropriately for devicesthat did not connect with at least reasonable frequency to the network,and accordingly is not preferred for devices that are not assured offrequent connections in a normal use pattern by an end user.)

Feature 22—DRM and Other Proxying

It may be desirable for a commercial or other content service to employany of a number of security-related features. These could include theuse of digital rights management (DRM) technology, which encrypts acontent file in a particular manner before it is transmitted/madeavailable to a receiving user device. Other security features mayinvolve requiring user/device authentication, or encrypted and securetransmissions of a certain sort. Microsoft® Windows Media® DRM is anexample of a DRM which is frequently used by commercial content servicesto protect content that is made available to end-users. It is alsoimportant to recognize that such a DRM technology is preferably used asonly a part of a larger system and may not be sufficient on its own tomeet the needs of a complete commercial content distributionsystem—i.e., the DRM technology itself does not include all itemsnecessary for a commercially viable content purchase, subscription orother commercially oriented system. In particular, information that isnot a part of the DRM system, such as personal identification, isnecessary to bill the end user for services and determine whatparticular digital rights a particular recipient is entitled to. In thiscase, it is necessary for the device maker to provide the means requiredto supply the “account”/user information needed by content providersystems to allow content to be delivered to and rendered by the device,and this information must be provided to the DRM system in a compliantand secure manner at the time the device is transacting with the backendcontent distribution systems.

It further may be desirable for a device maker or service provider toallow an end user to access any of a variety of existing or futurecontent services from a single device, which services may or may notemploy any or all of these security means in the course of providingtheir services.

It may be difficult to enable access to these secure services from thedevice due to inadequacies of the device. For example, if a new securecontent service comes into being, a device may not have adequateprocessing power to handle certain aspects of the security, or may havedifficulty complying with a required authentication protocol unless itsfirmware/software is upgraded. In particular, for example, a problem forDRM-based services might be that a proper DRM request to a serverrequires a requesting device properly combine the content request withauthentication information in a form that is encrypted in a particularmanner, before it can be issued a valid DRM license that would enabledecryption of the content during playback rendering and/or otherfunctions. Further, there is potential that the service will laterchange its requirements for this process. This may happen frequentlyover time, for example, because hackers eventually “crack” the securitymeans and it is necessary to employ a new one or make modifications, orbecause the service seeks to implement new security features or a newversion of the DRM. Further, complications may arise when multipleservices use multiple types of DRM or other security measures, which mayin particular create operating issues for a device of limited means suchas a mobile device.

This problem poses a significant issue for device makers and contentproviders. Even if difficulties can be overcome to enable a device toconnect to a particular service, these companies face the risk that afuture version of the service or the addition of a new desired servicewill make the device incompatible, resulting in angry end users. Inparticular, if the device maker or other intermediary in thedistribution chain does not control each of the services being provided,it may not be possible to make a change on the server-side to repair theproblem. Accordingly, these parties are faced with the difficult choiceof requiring an update of the software/firmware on the end user devicesin the field, such as a wireless mobile phone, either by over-the-airdownload or by sideloading. This creates a potentially undesirablesituation for the parties involved, as this creates potentiallysignificant inconvenience for the end users, impedes the entertainmentor other experience the providers are attempting to provide, and createsrisk, cost and time involved in creating the upgrade for the handset. Asolution that does not require modifying the software/firmware on thehandset is accordingly strongly preferred.

The present invention seeks to solve this problem by providing a proxyto a DRM request or other security means via a server-side request madeon behalf of the device as shown in FIG. 4. In this figure, system 300includes a external content provider 302 or other means used to storecontent and to release the content to various devices 304, 306 and 308using the process described herein.

The external content provider 302 exchanges data with an intermediaryserver system 310 that is connected to the Internet 312 for sendingcontent to the devices 304-308. Through this intermediary server 310,the devices 304-308 are insulated from changes that may occur andprotected from requiring ongoing modifications and upgrades.Significantly, it is also a mechanism whereby a single device can easilyacquire content from a plethora of content providers, even ifpotentially different compliance requirements/protocols are required bythe various providers to obtain content from the service. To ensure thatsecurity is still effectively provided, the device (e.g. 306) identifiesan intermediary server 310 as a first point of contact for a specifiedclass of transactions (or all transactions, depending on the desiredfunction of the device). The device 306 and the intermediary server 310establish a preferred authentication/security means, so that theintermediary server 310 can always authenticate and handle securecommunications to the device 306. The intermediary server 310 has ameans to identify, authenticate and collect valid user/accountinformation of the devices/end users 306-308, as needed to enable thesupported services, for example by using a look-up table.

As an example, in the event the device 306 seeks to downloadDRM-protected content, it sends a request to the intermediary server 310(in particular, this may include an identifier for the content desired,as well as authenticating data identifying the device to theintermediary server 310). Based on the request, the server 310 thenrecognizes that the device 306 is seeking to access content from aparticular external content provider—for example, a provider ofDRM-protected music content files. The intermediary server 310, which isroutinely kept updated by a server-side team, contains code which knowsto reformulate or translate the DRM content request from the device 306into a well-formed query that is suitable for example for externalcontent provider 302. In particular, with, for example, Microsoft® DRM,the query may involve combining certain individualized information ofthe device with the request, plus information contained at the serverlevel which may pertain to a “master account” established between theintermediary server 310 backend and the content provider's servers 302,or information pertaining to an individual account on the contentprovide that was created on behalf of the device by the intermediaryserver. The intermediary server 310 then makes this request on thedevice's behalf to external content provider 302, and receives back aresponse (in certain cases, potentially after multiple requiredback-and-forth authentication-related exchanges) which the device 306 isable to interpret (alternately, if an error code is received, the servermay similarly be updated to intercept and cure the error, oralternatively to interpret these error codes and provide an appropriatetranslation of this error to the user device so that its currentsoftware version is able to translate and make use of the errorinformation). This response is then passed on to the device 306, whichmay for example consist of a URL from which the device can obtain thedesired content file.

This proxying of the DRM request has thus insulated the device 306 fromissues of changes and other problems that may occur in an ongoing andevolving security environment. It has further allowed an intermediateserver 310 to offer content to the device 306 from a plethora ofexternal content providers 302 without the device 306 user needing todirectly establish a business relationship with each provider 302, or toimplement a multitude of access or security protocols on the device 306that may be needed for each particular provider 302. (The operator ofthe intermediary server 310 can opt to automatically aggregate certainservices for its users in this fashion, or alternatively can takeanother approach, such as allowing users to manually specify from thedevice interface or a PC which of the supported services they would liketo add to their accounts.) It also has the further benefit that, in theevent the device 306 has only intermittent connectivity and thenegotiation of the security protocol could take time while the device306 is “on hold” between interim responses, the server 310 can carrythese transactions out even if the device 306 has lost connectivity inthe interim. It has further provided more flexibility for the operatorof the intermediary server, who can choose to provide more or lessinformation to the external content providers as desired, based forexample on a desired business relationship.

Feature 23. Music4U/Send-to-Device

With devices that are able to connect directly to a network (e.g., theInternet) in some way, there is potential for users to obtain contentdirectly, without using an intervening device such as a PC. However, aproblem faced by many users, device makers, service providers and othersis that the user has a vast/enormous selection of available content tochoose from, and it is difficult to navigate/search/browse, identify,order, download, play and manage content that is well-suited to the enduser, particularly from a device with limited user input and output suchas a wireless mobile phone.

By contrast, while still a difficult problem, users have a somewhateasier time browsing and navigating available content when they use atraditional PC, which typically offers a larger screen and moreavailable and navigable input devices, such as a mouse and keyboard (andpossibly a more stable, speedy and economical Internet connection).Further, as PCs typically establish a more “always on”-type connectionto the Internet, Internet-connected content services are able to providestream-able and downloadable samples on-demand to help users determinecontent that is appealing before committing to what is often a longerand more involved download process to obtain the full content, or priorto making a purchase or other business commitment.

Content services that enable content access on portable and otherdevices typically require users to make selections on a PC, and thenmanually connect the device to the PC—perhaps through a USB or“Firewire” connection—to transfer the content from the PC to the device.

The present invention allows users to maintain the advantages of the PCin identifying and selecting content, but avoids the need for the userto manually connect a mobile or other device to a PC through a localconnection. The process is illustrated in a somewhat simplified versionin FIGS. 4 and 5. The process 400 starts in step 402 with a userentering his orders, preferences and/or selections via any connecteddevice, including via use of a browser on a PC or other device. Theserequests are stored on an intermediate server, such as server 310. Theuser may accordingly use a PC or any other desktop or hand-held devicefor searching, browsing, sampling, etc., and then make a selection to“send to device” any or all of the content he/she is finding via thesearch, to have the desired selections remotely sent asynchronously tothe target device. The selections are stored by the intermediate server310 until a specified mobile or other device (or, potentially, all PC,mobile and other devices associated with a particular user's account)makes contact with the intermediary server 310 (step 404). At that pointthe server 310 notifies the respective device that selectedcontent/preferences, etc. are being cached and are ready for delivery tothe device. The device then automatically request download of thecontent and other items that the server 310 has made available.(Further, a syncing mechanism can preferably be used to manage conflictsthat may arise between actions a user took on the device and the server310, or to manage conflicts between local preferences set by a user forone device and new content that becomes available.) (Step 404)

In one implementation, for example, a new user can join a commercialservice via a Website. The user can quickly be prompted to providespecific or general information about his/her preferences—for example, auser can indicate a preference for jazz music and 80's rock music,and/or specify a preference for music of Ray Charles and Beyonce. (Thisinformation may alternatively or additionally be collected in otherways, such as by monitoring preferred content selected by a user in thecourse of using the service, by observing behavior when renderingcontent such as “skip/FF” or “don't like” button presses, or othermeans.) After entering this information the server can use thisinformation to generate a proposed playlist for the user. Playlistgeneration can be achieved via a multiplicity of ways or anycombination, which are known to many experienced in the art. Theyinclude, for example, recommendation technologies that use Bayesianstatistics, manually-created artist/genre/track associations,content-analytic techniques, and other methods. In its simplest form,pre-made playlists may be created and stored on the server, and inputsfrom the user can be made to trigger a complete or partial/randomselection from the pool of selections included on the relevantplaylists. Content can continually be added and cycled on the playlists,such that they appear to be “endless playlists” or radio station-like inappearance to an end user.

Once the playlist is generated, the user can opt to have this playlistsent to his/her device (or, preferably, this step can be madeautomatic). At this point, the server will store a record that theuser's device should be updated with this playlist and content at thenext opportunity. The next time the server detects that the device hascontacted it, the server informs the device that there is cachedinformation waiting and makes a specific URL or other means availablefor the device to download the cached content. In this way, settings andselections of the user that were entered through a PC interface are sentto the user's device. The user need not struggle through a limited userinterface, screen, and input means to select content from a vast catalogof available content. The user also need not manually connect the deviceto a PC and make a secondary transfer over a USB cable or other means.Instead, this step is automatically accomplished.

In one further variation, the user may indicate a desire for contentmatching his/her preferences to be periodically sent on an ongoingbasis. In this case, the server can be made to periodically createadditional playlists (which do not overlap the content previously sentto that user, except to the specific extent desired), and to repeat theprocedure above whereby it makes the content available to the device. Inthis way, a user need not even revisit the PC to change preferences butcan always receive more content.

In another variation, users can be offered a means on the mobile deviceto say “more” or the equivalent, and accordingly demand that morecontent meeting the preferences be provided. This can be in addition tothe automated server pushes described above. Related to this, the usercan be given access on the mobile device to enter all or a portion ofthe preferences described above, such as preferred genres of music andpreferred artists, so as to obviate need to utilize the PC at any point.

Further, as may be directed by the server, the new playlists can eitheramend or modify, or completely replace, playlists that were previouslymade available to the device. In this way, more incremental changes canbe made to the playlist over time, providing a balance of “core” or“essential” music on the device with new, fresh content. Preferentially,the device also provides more information back to the server about theuser's behavior, which is further used to enhance the user's experienceand relevancy and attractiveness of the content selections. Inparticular, the device may report what songs were played (and, byimplication, not played) by the user, as well as which songs wereskipped (and, by implication, played and not skipped) by the user. Thisreporting can all take place on a mobile phone, for example, byover-the-air sending of data at opportune times, in an asynchronousfashion.

Numerous modifications may be made to the invention without departingfrom its scope as defined in the appended claims.

1. A system for distributing and playing musical selections comprising:a server; a plurality of portable devices, each device including a musicselector and a music player, said devices being selectively connected tosaid server through a distributed computer network; wherein said serverprovides lists of musical selections to said devices; wherein a user canselect specific musical selections for his device using said musicselector, said selections being transmitted to said server; and whereinsaid server sends musical selections to the devices based on thespecific musical selections selected by each user.
 2. The system ofclaim 1 wherein the user makes his specific selection while his deviceis offline.
 3. The system of claim 1 wherein said server communicatesexternal sources for the transmission of musical selections to saiddevices.
 4. The system of claim 1 wherein said musical selections arepodcasts.
 5. The system of claim 1 wherein said server pushes musicalselections to said device.
 6. The system of claim 1 wherein said serverdelivers and updates playlists of musical content.
 7. The system ofclaim 1 wherein said content incorporates content-protection securitymeans.
 8. A system providing content to multiple users, wherein saidcontent is protected by DRM rules comprising: a plurality of devices,each device having input members receiving content requests fromrespective end-users; and an intermediate server connected between saiddevices and at least one content provider, said intermediate serverreceiving a request from one of said end-users, translating said requestinto a new request compatible with DRM rules and transmitting said newrequest to a content provider.
 9. The system of claim 6 wherein saidintermediate server exchanges information with several content providersand wherein said intermediate server sends said new request to thecontent provider associated with the requested content.
 10. The systemof claim 6 wherein said intermediate server receives requests fromseveral devices, said intermediate server generating said new request byaggregating the requests from the several devices.
 11. The system ofclaim 6 wherein an alternate security means or access protocol isutilized in place of or in addition to the DRM system.